The Internet Protocol (IP) Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an architectural framework for delivering IP multimedia services, including Voice over IP (VoIP), video calls, etc. IMS provides services for any type of IP communication whether it is voice or video telephony, video streaming, instant and multimedia messaging, multimedia gaming or virtual-reality.
In IMS, the Media Resource Function (MRF) provides media related functions such as media manipulation (e.g. voice stream mixing) and playing of tones and announcements. In IMS, the Home Subscriber Server (HSS) contains subscription-related information, performs authentication and authorization of the user, and can provide information about the subscriber's location and IP information, playing a role similar to the GSM Home Location Register (HLR) and Authentication Centre of the 3G/2G mobile network. The HSS is a centralized database for IMS, Packet Switched (PS) and Circuit Switched (CS) entities.
In mobile networks, apart from answering and rejecting a call, incoming call management capabilities provided by mobile network operators tend to be limited to a pre-defined configuration that applies to every incoming call. This pre-defined call management configuration results in diverting all incoming calls to a specific alternative number (e.g., voicemail) when engaged, or when a call goes unanswered.
Current solutions providing additional incoming call management capabilities fall into the following two categories: device-based and call-forwarding.
Device-based solutions consist of an application residing on the user's handset that is notified by all incoming calls. The user is provided with prompts for how to handle the call. Examples include the Reject++ app for Android, or the calling functionality built into Apple iOS 6 that allows the user to decline any incoming call by replying automatic and instantly with a text message or setting a callback reminder, among other options. But these device applications need to maintain the connection between the caller and the service via the incoming call (i.e. they cannot disconnect or reject the call). This means that even if the phone does not have an active call, for a network perspective, the caller will be busy. Therefore, any actions that require the caller to remain connected (e.g., to receive an automated audio message or announcement) requires the call recipient to be unavailable (i.e., future incoming calls will receive the busy signal and the network will identify the caller status as busy). Also as the connection must be made directly to the device, roaming charges will apply only when the device is off-network. Therefore, the caller user does not have real time feedback of a call being rejected.
Call-forwarding solutions utilise the standard network call forwarding capabilities to forward every call to a third party service that then provides further capabilities (usually in conjunction with an application on the phone). Examples include HulloMail and Google Voice. As these applications require the forwarding capabilities of the network, they may result in slower response times (while the call is forwarded, followed by the action be requested and then executed). As users have the ability to change call forwarding settings for their account, they cannot realize the impact to any such call-forwarding service already configured. Another limitation is that call-forwarding solutions cannot work in roaming scenarios, since only the home network may know how to route the call.
There is therefore a need for providing users with the ability to manage incoming calls on a per-call basis, even in roaming network scenarios, as well as providing user devices with more variety of call management related capabilities which allow the user to decide per call basis what to do with the incoming call (e.g., automatic reply by sending a Short Message Service (SMS) to the caller) but without requiring previous configuration of the device by the user.